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Abstract—Type systems are crucial tools in the hands of 
developers to ensure an increased level of soundness to their 
programs, make them safer, and guard against bugs. However, 
in practice, the type system is not always used to its full capability, 
and trade-offs are made. The effects range from hindered 
code comprehension and wasted development effort to financial 
damages and even the risk of loss of life. Various widely used 
programming languages, such as C+, Java, Python, and Rust, 
are yet to implement constrained types as a language feature. 
While the usage of user-defined types is common in modern 
languages that support such elements, developers often resort 
to having their variables use the most common, fundamental, 
built-in or library types, such as int or string, and not encode 
invariants into the type system. In this paper, we describe a 
flexible, incremental, semi-automated type migration approach 
that allows transitioning from the use of fundamental coarse types 
to strong types. Previously, well-scaling type migration methods 
were restricted and required the existence of an already well- 
defined destination type. In our case, the new strong type to be 
created is not yet defined, but the required interface is discovered 
via static analysis. As refactoring tools would cease to function if 
the code is changed textually to a version that refers undefined 
symbols, a more granular approach was needed. In addition, our 
proposed method allows us to discover the mixing of conceptually 
distinct types during development while the original program 
continues to function. 

Index Terms—strong types, C+ programming language, soft- 
ware refactoring, static analysis, type safety 


I. INTRODUCTION 


Type checking is often only done by the compiler, and in 
the past, the set of usable types was coarse and only distinctive 
between broad concepts. While some programming languages 
have allowed the developer to define their own types for 
a long time, in many cases, developers resort to using the 
most conceptually fundamental types instead of fine-grained 
strong types. Thus, type systems are not used to their full 
extent in most software projects. The lack of semantically 
meaningful types for variables and values in the program can 
result in a variety of problems. The most benign case is that 
code comprehension is hindered, especially if the variable’s 
name is not indicative of the semantics behind the potential 
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values (1). However, the lack of strong types can lead to 
severe financial damages or even loss of life. An infamous case 
of this was the Mars Climate Orbiter spacecraft’s explosion 
in 1999 (2). The scientific research and development effort 
required to undertake space flight required contributions from 
all over the world, which resulted in a fatal development 
mistake to be left in the controller code, which resulted in 
the accident. With no knowledge of the presumption that the 
floating-point numbers across some subroutines were expected 
in metric measurements (N +s), an interfacing code developed 
by another team passed values in imperial measurements 
(Ibf +s) to it. Assuming that such software is written in a higher 
level programming language]! | this family of mistakes could 
be caught if distinct types existed for the units, as a compiler 
during semantic analysis most likely would have been capable 
of reporting the type mismatch as an error. 

The extent of support for type granularity varies between 
programming languages. Some programming languages, like 
Ada, allow for easy definition of unit types or range- 
constrained numerics, and support these types with the ap- 
propriate compile-time and run-time checks. In other pro- 
gramming languages, support for constrained types and unit 
types are possible through the creative application of exist- 
ing language features (such as template metaprogramming 
in C+ [3], [4]) or by the usage of libraries. If no library 
solution exists, developers may still ensure a fine-grained and 
strong type hierarchy in their software by merely writing the 
types in their source code. Unfortunately, when it comes to 
widely used, built-in, or general enough types, such as int for 
whole numbers, double for floating-points, or string for any 
textual data, developers usually overlook the need for creating 
strong types and resort to just using the built-in or standard 
library (5). This has also led to real vulnerabilities in large- 
scale source code (6). 

Having established the need for strong types, the issue 
of effort arises. Modern software projects are not worked 
on “from scratch”, and as such, there is always an existing 
codebase the project depends upon and interacts with. Simply 


'It is not detailed in the official investigation report what programming lan- 
guage or environment — if anything else than some Assembly-like embedded 
microcontroller code — was used for the actual development of the culprit 
software modules. 


defining a new type in the source code and changing symbols’ 
types to the new type is not sufficient as the existing codebase 
will break due to the lack of well-defined operations and 
undefined conversions. Once a software project’s source code 
is broken in such a way, most tools can not interact and work 
with the gathered information anymore. Existing type migra- 
tion techniques replace the occurrences of one particular type 
with another while ensuring the replacement still compiles. 
However, these approaches do not apply if only a subset of 
the usages of a particular type needs replacement. To ensure 
that the software project is transformed in a way that it keeps 
its behaviour and the invariant that the code is always legible, 
in this paper, we provide a method that allows incremental 
refactoring of the existing codebase. It has been proven and 
reproduced in studies that code quality metrics only improve 
if a significantly motivated developer takes the process of 
improving the metrics as a personal goal (7). As such, we 
position our approach to be used in a tooling environment to 
solve the issue of coarse and weak typing incrementally in an 
existing codebase (8). We show that the careful discovery of 
how a particular symbol is used can be done via static analysis. 

Our approach takes knowledge about a program element 
from the developer and helps transition the affected, related 
program elements to a new, strong type. This strong type 
then immediately prevents several families of misuse — e.g. 
the mixing of measures from different dimensions or units 
— but keeps the existing behaviour of the existing code 
in place. Combined with other methods, such as invariant 
synthesis, these strong types can then be developed to achieve 
a higher level of encapsulation and feature expression, where 
specific invariants are encoded and checked at compile-time 
or run-time. This latter part of the work is designed to be 
done by a developer with domain-specific and project-specific 
knowledge. 

This paper is organised as follows. In Section [I] we show 
the state of the art literature and tools that are related to 
enhancing type safety. We also include the general blueprints 
that help create strong types from existing routines manually. 
The overarching process of our proposed type migration 
framework is discussed in Section The first major step 
in the process is described in detail in Section [IV] We discuss 
improvements to the approach in Section [V] Conclusions are 
drawn in Section 


II. RELATED WORK 


Traditionally, and due to the lack of granular design, devel- 
opers have been embedding information about a variable’s 
conceptual domain in the variable name while leaving the 
type of the variable be a fundamental/primitive type or widely- 
used library types, such as int, double, or string. This 
practice has been criticised due to how it impedes code 
comprehension and how it allows for error-prone programming 
practices due to lack of type granularity. Butler et al. (1). (9) 
described means to extract meaningful identifier names from 
Java source code. Liu et al. investigated the connection 
between formal parameter names and the names of arguments 


passed. They concluded in their empirical study that the 
similarity in most cases takes the two extremities: either very 
high (almost or precisely the same) or very low (dissimilar). 
Extending these works, Rice et al. (6) have integrated an 
automated check for argument selection mismatches to their 
development pipeline at Google Inc. and evaluated their im- 
plementation on substantially sized corpora of Java projects 
spanning 200 million lines of code, including proprietary and 
open-source. They discuss several long-living bugs in the 
analysed projects that stem from functions taking multiple 
parameters of the same declared type, allowing the developer 
mistake. Szalay et al. argue that languages that allow a 
broad set of implicit conversions, such as C+ or Scala, are 
especially more dangerous to use because there are more 
dangerous interfaces at function boundaries. 

Several works in the literature discuss the automated, tool- 
driven synthesis of type constraints. Guo et al. detail 
how run-time interaction between variables can be used to 
infer similarities in the concept represented by some variables 
and thus unite these variables to have a common, shared type. 
Hangal and Lam propose a tool that automatically corrects 
errors in Java programs related to dimensionality — e.g. using 
an integer variable representing a square number (such as 
area) for a scalar (such as length) variable. This tool does 
interprocedural context-sensitive analysis and infers possible 
dimensions or units for variables from their usage points. 
RefiNym is an automated unsupervised learning tool that 
models the flow of values and expressions from one variable 
to another and suggests more fine-grained types based on the 
information gathered. The CheckerFramework is a Java 
tool which uses annotations — a technique similar to attributes 
in C+, which we use — to add additional semantic information 
and enhance compile-time type checking to source code. This 
tool is widely used in various multinational corporations such 
as Amazon or Google to enhance the adherence to rules of 
thumb that were synthesised from multiple decades’ worth of 
studying real-life developer mistakes and oversights. 

Type migration, which is the core operation that our 
approach aims to enable, has been shown to be feasible in 
large codebases (15). However, in most cases, only one-to-one 
(or n-to-n) mappings were established, without the explicit 
need for mining and discovering what operations have to be 
migrated. Refactoring efforts on modern, large-scale systems 
not only have to ensure that behavioural semantics are kept, but 
there are also other requirements. One such requirement is that 
refactoring should not be atomic to ensure that changes 
propagate across library or product boundaries incrementally. 
Previous studies show an at first non-intuitive finding that 
developers actually employ refactoring tools for functional 
changes too (17). |18]. There are several reasons as to why 
developers would refrain from using refactoring tools (19). 
Developers tend to favour smaller-scale simple refactorings 
because tools more often than not are perceived as non- 
trustworthy [20]. Eilertsen and Murphy conducted a 
study in which developers had to perform software change 
tasks prepared by the researchers from real-world refactoring 


void bad_draw_function(int width, int height); 
struct Width { 
int value; 


explicit Width(int v) : value(v) {} 

explicit operator int() const { return value; } 

int operator() () const { return value; } 
}; 


struct Height { /* Analogous ... */ }; 
void draw(Width w, Height h) { 
// Discarding the strong alias: 
int wil = w.value, 
hel = h.value; 
int wi2 = w(), 
he2 = h(); 
int wi3 = static_cast<int>(w), 
he3 = static_cast<int>(h); 
} 
bad_draw_function(1, 2); // Works, but dangerous! 


# error: no conversion from ‘int! to ‘width" 
draw(l, 2); 

¥ error: no conversion from 'Height' to 'Width' 
draw(Height{2}, Width{1}); 

draw(Width{1}, Height{2}); VY Works! 


Listing 1: Transformation from a low-granularity built-in type 
to a semantic typedef or wrapping type makes the used type 
explicit and prevents assigning the wrong parameters in the 
call. 


commits and report on their experience with tools or the 
reasons why they did not use some of the tools during and 
after the assignment. The authors proposed a new theory for 
gauging the usability of refactoring tools and propose several 
new elements the developers of such tools should also focus 
on, such as allowing developers to guide the tools’ behaviour 
and that tools explain the changes made to the software 
project. Previous works of Yamashita and Moonen and 
Kovacs and Szabados [7] observed that the evolution of 
software systems is predictable and follows trends. More 
importantly, it requires the internal motivation of developers 
who are able to allocate time for improving code quality. These 
observations added together means that there is a sensible need 
to develop refactoring methodologies that earn the trust of 
developers, and thus will more probably have them internalise 
the need for the refactoring provided, which they will solve 
with the tools given. 


A. Distinguishing variables of the same type via strong aliases 


C and C+ allows developers to create aliases of types with 
the typedef and using declarations. At first glance, they might 
seem like an excellent way to distinguish variables using 
types, but the distinction is only visual: the language and the 
compilers draw no distinction between the original type and 
the alias. 

The easiest way to ensure type granularity and prevent 
misusing weaker types in ambiguous contexts is to use wrap- 
per types, also known as “strong typedefs” or explicit type 
aliases. An example of wrapping two plain ints into strong 


#include <chrono> 
using namespace std::chrono; 
using namespace std:literals; 


Bad: prone to bad order of arguments, 
some (but not all) semantic information 
found only in parameter names. 


bool submit_bad(int year, int mon, int day, 
int hour, int min, int sec); 
submit_bad (11, 59, 8%, 10, 14, 2021); 


Good: well-defined, 
strong type used. 
bool submit (time_point<system_clock, 
auto dlDay = 202ly / Oct / 14; 
auto dlSecond = 24h - 1s; // = 86399 sec 
auto deadline = zoned_time{"Etc/GMT-12", 
dlDay + dlSecond}; 


semantically checkable 


seconds> T) { 


return T < deadline.get_sys_time(); 


} 
submit_at_good(system_clock:now() ) ; 


Listing 2: Comparing traditional, not safe versions with using 
stronger types and type-safe “strong” literals for representing 
time and deadlines with the Chrono library. Program execution 
shows as exit status whether the deadline has not been hit 
yet. (‘—’ sign in timezone name is inverted according to ISO 
standards, “Etc/GMT-12” indicates UTC-12.) 


aliases can be seen in Listing [I] The transition from the low- 
granularity type to a strong alias is explicitly visible in the 
code. The technique has no run-time performance drawback, 
as all major compilers optimise the conversion functions’ calls 
away. Given the additional function calls being optimised out 
and due to value semantics, the size and behaviour of the 
semantic typedef instance are the same as the single variable 
contained within, with no additional steps to take at the 
destruction. Parallels can be drawn between this approach and, 
e.g. the newtype language element in Haskell, which defines an 
explicitly boxed strong typedef over another type with offering 
no operations apart from conversions. This type is only used 
for type checking and is eliminated from the code in the 
pipeline early on, leaving only the underlying type to exist 
during execution (23). This is not the case for Java, where 
heap allocation is potentially done, and the conversion to and 
from boxing types cause a performance hit (24). 


Semantic typedefs offer an easy and straightforward solution 
but cause an explosion in the number of types visible in scope, 
which may hurt compilation time and lessen development 
productivity (25). Built-in support for such language elements 
is part of neither C nor C+. There had been proposals (26), 
to include opaque typedefs as a language element of C+, but 
these have not made it into the language yet. Similarly, Barath 
and Porkolab discusses a wrapper class over numeric 
conversions. Instead of explicit wrapper classes, scoped enu- 
merations (enum class) disable most dangerous conversions, 
but the requirement of having named enumerators makes them 
only contextually useful. 


B. Strong types, strong literals, and dimension libraries 


A particular issue with wrapping types is that their usage 
solves only the problem of conflating values of different 
conceptual types to the same receiving symbol, such as in 
the case of an assignment or passing arguments to a function. 
Apart from argument-forwarding functions, the developers 
would always wrap and then unwrap the value, and within 
the business logic of the program, the wrapped type would be 
used. Strong typing (29). in which the expressive capabilities 
of the type system and types used in the program is increased, 
has been investigated for their effect on language design 
and as a method to increase type coherence for persistent 
systems and to prevent security vulnerabilities in web 
applications [32]. 

A more actionable solution is to increase the type safety 
of the project by introducing user types and relying on the 
compiler to find type non-conformance violations. It is very 
likely that there are hidden invariants [25], [33}. behind 
most of the int or char variables that are checked somewhere 
during execution. Such cases could be transformed into types 
that ensure invariants. One such invariant could be that a 
numeric value must be within a specific range, narrower than 
the fundamental type would allow. Another case could be 
specific patterns a string-like variable must adhere to, e.g. 
it is a time code or a name. All these improvements allow 
expressing the domain concept within the source code itself, 
as opposed to only human-readable channels such as naming 
conventions or printed documentation. 

When it comes to strong typing, the cornerstone example 
is Chrono, the C+11 standard library for representing time and 
duration, which is related to our work in terms of leveraging 
the type system to express and enforce dimensions at compile 
time. Listing |2} shows an example code where strong types 
are used to express date and time operations. Chrono can be 
viewed as a solution that aimed to solve some issues discussed 
in this paper for the particular, well-defined domain of date and 
time, and succeeded in doing so. Other solutions that enforce 
dimensionality through the type system exist for physical 
units (35). Several other libraries aim to exploit existing 
language features to allow general stronger typing (36). 

Wright details a method for migrating coarse-typed 
systems mostly using the built-in type double to represent 
time-related concepts to the abseil library. They designed 
the algebra and logic specific to identifying usages in the 
existing codebase and having implemented this transition as 
clang-tidy checks. Their type migration effort differs 
from ours due to the Abseil time library having been designed 
in advance. Their goal was to take an existing code and 
an existing target granularity and perform the transition. In 
contrast, our proposed method aims to allow the developer 
discover the interface concepts during the type migration 
process. 


Il]. THE TYPE MIGRATION PROCESS 


Migration of existing software systems to a new set of 
types is known as type migration. However, existing type 


[[fictive_type (temperature) ]] int T; 


Listing 3: A variable of type int attributed with belonging to 
the fictive type temperature. Most traditional compilers will 
continue to use the variable as a conventional integer. 


migration utilities fall short of the problem unless the types are 
mapped one-to-one. Domain-specific refactoring efforts (such 
as in (37) can help transition between types in well-defined 
contexts, but these tools have to be tailored to a particular 
domain and not offer a general solution. In addition, designing 
a domain-specific algebra that is capable of transforming a 
pre-defined set of types to another type requires a precise 
understanding of the conceived type and how it interacts with 
the rest of the system. Code comprehension tools or synthesis 
tools might aid these efforts. 

We propose a flexible semi-automated type migration pro- 
cess that combines elements of code comprehension, data 
flow analysis, taint analysis, and program slicing. It allows 
developers to become familiar with the usage places and 
the required operations of the to-be-introduced during the 
refactoring process itself. The following description will be 
from a C+ developer’s point of view. However, the approach 
is general enough to be implemented for other languages, 
provided a sufficient understanding of their specifics is taken 
into account. 

The process involves three major steps, during which 
changes are made to the source code. We start with the 
assumption that the input source code correctly describes the 
programmer’s intent. The exploration is capable of identifying 
collisions and confluences in the data flow if multiple initial 
inputs are given simultaneously. 


I. Adding the initial taint or seed 
II. (Iterative) exploratory propagation 
Ill. Code rewriting 


The type migration process is facilitated through the use of 
fictive types, which allows us to add an additional conceptual 
property to program elements. We use the term fictive to 
distinguish the new type the program element shall belong 
to from the “actual” or “concrete” type it belongs to currently. 
The fictive type conveys the program element’s membership 
(€) in a conceptual set of values. 

Thus, the fictive type is an annotation, which in practice, 
can be represented by C* attributes. Attributes are a lan- 
guage element introduced to the standard in C+11, represented 
by the [[attr,, attre, ...]] attribute-specifier-sequence|’| The 
Standard defines some attributes, but compiler vendors are 
allowed to reuse the attribute syntax to provide their own 
additional attributes. If a particular compiler does not define 
the meaning of an attribute encountered, the default behaviour 


? Attributes were originally introduced as means for developers to control 
the optimiser and code generation pipeline of the compilation process. For 
software projects built upon older C++ versions (or C), the GNU GCC 
language extension format __attribute_((attri, attra, ...)) 
can be used. It is generally interchangeable and understood by most major 
compilers. 


// Round an integer representing a single-digit 
// decimal to a whole number: 

// 242 —+ 240. 247 —+ 250. 

int whole_degree(int T) { 


int whole =T / 10; 
int fracture = T % 10; 
return (fracture > 5 ? (whole + 1) : whole) x 10; 
} 
// Read an integer from a data pin set. 
int sensor_read(unsigned short connector_id) { 
std:zbitset<sizeof (int)> bits; 
for (int i = 0; i < sizeof(int); ++i) 
bits[i] = (PINS[connector_id] [i] == V_HIGH); 
return static_cast<int> (bits.to_ulong()); 
i 
// Write an integer bit-by-bit to a data pin set. 
void control_write(unsigned short connector_id, 
int value) { 
std:bitset<sizeof (int)> bits{value}; 
for (int i = 0; i < sizeof(int); ++i) 
PINS[connector_id] [i] = bits[i] ? V_HIGH : V_LOW; 


// Pulse the clock and let the other side read. 
analog_flush(); 
} 


int main() { 
while (!check_shutdown()) { 
[[£t (temp) ]] int desired = config["TARGET"]; 
[[£t (temp) ]] int Tl = sensor_read(S_TEMP_1); 
[[£t (temp) ]] int T2 = sensor_read(S_TEMP_2); 


int icon_to_use = 0; 
if ((T1l + T2) / 2) > desired) 
control_write(C_AIRFLOW_1, 
whole_degree (desired) ); 
control_write(C_AIRFLOW_2, 
whole_degree (desired) ); 
COOLING_ICON; 


{ // Turn on. 








icon_to_use = 
} else { 
control_write(C_AIRFLOW_1, 
control_write(C_AIRFLOW_2, 
icon_to_use = STANDBY_ICON; 
} 
control_write(C_LCD_TEMP, 
control_write(C_LCD_ICON, 


// Tarn off, 
0); 
0); 














(Tl + E22) ¢ 2s 
icon_to_use); 


} 


Listing 4: The initial seed added to an example project. 
Temperatures are represented with a hidden invariant. 
fictive_type (ft) and "temperature" ("temp") abbreviated 
for readability. 


is to ignore the attribute and issue a warning to the developer. 
This fallback mechanism allows using attributes as an in-band 
vessel to store arbitrary information. While various tools use 
attributes to encode information which is intended to stay in 
the code (39]-(41), fictive types are a transitional mechanism, 
and after the type migration, the code no longer needs to 
contain the attribute. An example of a variable’s fictive type 
declared on the variable declaration can be seen in Listing B] 


A. Adding the initial type seed (taint) 


The type migration process begins with a developer identi- 
fying, through inspection, code comprehension, evaluation of 
metrics, or invariant synthesis [42], [43], etc., a value-carrying 


int random() { 
[[ft (random) ]] int R = 4; 
return R; 


4 


[[£t (random) ]] int random() { 
[[ft (random) ]] int R = 4; 
return R; 
} 
Listing 5: Propagating the fictive type of the local variable 


to the function’s return value changes the function’s interface. 


(Application of rule [(4]- see Section [IV-A]) 


program element — in most cases a variable or return value of 
a function — that is not strongly typed enough, and adding 
an initial annotation, as seen in Listing [3] to the source code. 
In the following, we will generally refer to variables having 
a fictive type. The process works the same way irrespective 
of how many annotations are added, and developers can add 
multiple distinct annotations, e.g. a set of variables belonging 
to 7, and another distinct set belonging to 72. A precondition 
is that, for the execution of the process, the fictive type’s 
name uniquely identifies the encompassed concept, i.e. the set 
of temperatures must mean the same in the entire analysed 
software. 

Listing shows an example of an embedded control 
system’s code. The code contains only built-in types and 
some generic, representation-oriented library types such as 
stdxbitset. A human expert of the specific domain decided 
that some of the int variables represent temperature values 
and should be migrated. The developer thus annotated Lines 
[31] [32] [33]accordingly. Other parts of the code were left intact. 


B. Performing the propagation 


Once the user seeded the project with the aforementioned 
attributes, the propagation process can be started. The goal of 
the propagation is to spread the seeded taint in the project by 
labelling the tainted nodes in the graph. C+ is designed for 
separate compilation (44). in which each compiler invocation 
has only the knowledge of one translation unit (source file 
and its includes), but the migration of types is a project-level 
action. Consider the example in Listing [5] where a taint from 
inside the function reaches the function’s interface. If this 
function is not local to the translation unit, a header file is 
likely also affected, through which this information is made 
available to other translation units. Unfortunately, this means 
that the propagation must be executed as an iterative process 
across the project. 

The propagation is performed as a conventional fix-point 
iteration. We detail the propagation process in Section [IV] and 
reserve this section as an architectural overview of the process. 
As there are only a finite number of program elements, the 
set of nodes in the syntax representation of the project is 
also finite. Due to each propagation step capable of only 
introducing new taint to nodes, we can be sure that the process 
terminates in a finite time. Just as most variables are expected 


not to have multiple types simultaneously, we define a variable 
belonging to multiple fictive types — a node painted to a 
superposition of colours — to be an error state. 

1) The propagation in practice: While designing the prop- 
agation algebra, we have simultaneously created prototypes of 
an executing environment which does the propagation in prac- 
tice for C or C+ projects. We used the Clang compiler fron- 
tend libraries for the implementation, as Clang is the most 
widely-known and widely-used free and open-source compiler 
available that offers a clear and concise node matcher and 
transformation layer. Countless tools build upon the abstract 
syntax tree (AST) representation which Clang can generate 
and make available for a source file. However, it is important 
to note that the propagation rules are not specific to Clang. 
Knowledge of the internal details of other compilers (and 
even other languages) are enough to implement our process 
for other ecosystems. In every iteration, the tool generates a 
set of new attributes to be inserted into the source code — 
this changes the persisted code to provide information to the 
next iteration —, or a list of decision-making points or errors 
that the user has to react to. In the latter case, the subsequent 
iteration starts with the off-band inputs (“configuration files’’) 
created by the user or an integrated development environment 
(IDE) editor. These customisation points are elaborated in 
Section 

2) Scalability and applicability for large projects: How- 
ever, in practice, finite time can still be infeasible with a 
naive implementation. Currently, the research is focused on 
the propagation rules’ algebra, and we plan to tackle specific 
scalability issues in the future. There are various promising 
approaches, such as ClangMR [46], which allows running 
code transformations emitted from the Clang infrastructure in 
parallel, across a distributed infrastructure. 


C. Transition to stronger types 


Once a non-error, non-contradictory fix-point state is 
reached, all meaningful nodes that have received a fictive 
type taint are annotated in the source code with an attribute. 
Now we can perform the type migration by generating the 
strong interface for the new type. A strong interface lies 
between a strong typedef or type alias (see Section [II-A) and 
a feature-rich strong type (see Section [II-B). The automation 
cannot generate a strong type with domain-specific semantics 
associated with it, and this task is given post-refactoring to the 
project’s developers. However, encapsulating the operations 
and providing a complete interface of the strong type alias 
ensures that the clients of the new type do not need to handle 
unboxing. 

Listing [6] shows the example code after type migration has 
been performed. We generate the strong interface from the 
blueprint described earlier. Then, as the fictive type attributes 
are a transitional vessel, the annotations are removed, and 
the annotated variables are turned over to the generated 
type, turning [[fictive_type ("temperature") ]] int T; to 
temperature T;. In operator calls, where the user specified 
that operators should take temperature variables, the explicit 


construction of the strong type instance from the literal value 
is added. The new code also clearly indicates the interface 
boundaries not traversed by the process at the user’s request 
by performing a static_cast<int> of the strongly wrapped 
value back to its underlying type. These casts are inserted at 
calls to control_write. 


// Strong typedef, as per Section [7-4]. 
struct temperature { 





int, v; 
explicit temperature (int v) _v(v) {} 
explicit operator int() const { return _v; } 
hi 
temperature operator +(temperature Tl, 
temperature T2) { 
return Tl._v + T2._v; 
} 
temperature operator x (temperature T, int i); 
temperature operator / (temperature T, int i); 
temperature operator % (temperature T, int i); 
bool operator < (temperature Tl, 
temperature T2); 
bool operator <=(temperature Tl, 
temperature T2); 
// --- 8< --- Generated code above... --- >8 --- 


temperature whole_degree (temperature T) { 

temperature whole =T / 10; 

temperature fracture = T % 10; 

return 10 « (fracture > temperature(5) ? 
(whole + temperature (1) ) 

whole); 


} 


[[fictive_type_ignore]] int sensor_read ( 
unsigned short connector_id); 
[[fictive_type_ignore]] void control_write ( 
unsigned short connector_id, int value); 





int main() { 
while (!check_shutdown()) { 
temperature desired{config["TARGET"]}; 
temperature T1l{sensor_read(S_TEMP_1)}; 
temperature T2{sensor_read(S_TEMP_2)}; 


int icon_to_use = 0; 
if ((T1l + T2) / 2) > desired) 
control_write(C_AIRFLOW_1, 
static_cast<int> (whole_degree (desired) )); 
control_write(C_AIRFLOW_2, 
( 
I 


{ // Turn on. 








static_cast<int> (whole_degree (desired) )); 
icon_to_use = COOLING_ICON; 
} else { 
control_write(C_AIRFLOW_1, 
control_write(C_AIRFLOW_2, 
icon_to_use = STANDBY_ICON; 
} 
control_write(C_LCD_TEMP, 
static _cast<int>((Tl + T2) 
control_write(C_LCD_ICON, 


i? Tuer off. 
0); 
0); 














/ 2)); 


icon_to_use); 


} 


Listing 6: The result of the process after migrating Listing [4] 
to a strong interface. The changes against the original code 
are highlighted with a grey background. 


While the execution of our proposed process had con- 
cluded, the example is far from completely refactored. For 


example, the developers might add a strong literal 5_dc 
instead of the explicit temperature{5} constructor call. The 
whole_degree() function could be moved to become a mem- 
ber function of temperature — perhaps even renamed to 
round() — turning the strong interface into an actual class. 
Several library solutions are aiming to solve the strong type 
representation problem (35), by employing various lan- 
guage elements of C+, such as template metaprogramming 
or concepts. We accept the presented verbose output version 
as sufficient. Therefore, our research effort focuses mainly 
on the questions of the taint propagation algorithm and the 
interactions with the user during the refactoring. 


IV. TYPE TAINT PROPAGATION 


In the following, we detail the individual rules and steps 
of the propagation algorithm. The propagation is an iterative 
part of the overarching solution, individual passes starting by 
taking the previous pass’ output emitted into the input code. 

C and C+ can be broken up into several feature sets (“cat- 
egories’”’), each increasing the complexity of the propagation: 


1. Pure procedural C with built-in types, excluding “strings”. 

2. C, with “strings” (zero-terminated arrays) included. 

3. “C with classes” [47]: C+’s introduction of object- 
oriented language elements and concepts, such as classes, 
encapsulation, member functions, overloading, names- 
paces. 

4. Full-featured C+, including templates. 


Several existing works target the issue of coarse-typedness 
involving built-in fundamental types ee and our alge- 
bra primarily focuses on this — category |1.)— too. Allowing 
developers to move away from the use of such types is shown 
to have the greatest impact on type safety [5], [10]. We 
considered strings special, because of how C was designed: 
the language does not define strings as a first-class language 
element, rather strings are represented as a character pointer 
(char) to the first element of a contiguous array of characters, 
that is terminated by a 0...0 bit-pattern (NuL-character, '\0'). 
Unfortunately, the type char» is not sufficiently fine-grained: it 
could be a pointer to a single character, it could be a pointer to 
an array of characters which is not necessarily a string, a string, 
or a non-typed binary representation of any other variable] In 
addition, the current algebra excludes tainting the template 
type parameters. We detail the reasons behind and explain 
further avenues to be taken regarding this in Section 

C+’s program elements at the syntactic level can be grouped 
into three major categories: declarations, statements, and 
expressions. An unfortunate restriction in the grammar is 
that expressions cannot receive attributes, i.e. constructs such 
as fun([[fictive_type ("temperature") ]] 8), the apparent 
annotation of a literal, are incorrect. However, during type 
checking in the fictive type domain, individual expressions 
are also given a (fictive) type, albeit this is not persisted to 


3Until the introduction of std:byte in C+17, the only portable way of 
looking at an object’s binary representation was to reinterpret_cast it as 
an (unsigned) char. 


Unary: 


- {Op: "++temperature"# Res: "temperature" 
- {Op: "-temperature"# Res: "temperature" 
Binary: 

- {Op: "temperature + temperature", 
Res: "temperature"} 

- {Op: "velocity * time", Res: "distance", 
Commutative: true} 

- {Op: "acceleration * time", Res: "velocity", 
Commutative: true} 


Listing 7: Configuration of the allowed built-in-like operations 
between fictive types. Setting commutative: true is a shortcut 
to define the reverse order binary operation with the same 
result. 


the source code. An excerpt from the code in Listing /4| as it 
is expressed inside the compiler is shown in Fig. 


A. Forward propagation 


Forward propagation rules infer the type taint of a usage 
or reference of a program element from the taint of the 
program element. Forward propagation works similarly to the 
conventional type-checking of the language and the data flow 
at run-time, and as such, the natural process for thinking and 
reasoning about the program. The production rules for forward 
propagation follow from the language’s definition and users’ 
expectations. 

x,y,... refer to variables. f,g,... refer to function symbols. 
y,0,... refer to (arbitrary) sub-expressions that appear in the 
code. ft(A) denotes the fictive type for the syntactic sub- 
tree rooted at A. $a denotes the expression in which the 
x variable is referenced (in most cases, “read’’). Similarly, 
$f(...) denotes the resulting value from the function call 
to an f function. # indicates an error state, which might be 
recoverable (40) or unrecoverable (4m). A recoverable error 
can be resolved interactively by the user by defining a new 
operation in an appropriate parameter or configuration of the 
propagation. 





1) Trivial flow: First, we list the trivial rules that follow 
from the act of passing some value between program elements, 
most commonly assignment-like statements. 


(1) ft($2) = ft(x) 

(2) fi($f(..)) = ft(f) 

3) y= 7 —> fely) = fey) 

(4) For a function f: return(y) — ft(f) = ft(y) 


(5) Given £(..., @, ...)! £(..-) Y +++) —> ft(a) = 
ft(y) 
(6) ft(_ 2? 7: 0) :=V, iff IV = ft(7) = ft(c), otherwise 


4 | 


The official if-then-else operator ?: in C and C+ is type- 
checked for y and o to have a common type to which the 
expression can be converted to, but due to our model not ex- 
pressing subtype relationships between fictive types, we define 
a stronger requirement in tule [(6)| Subtyping would make the 
model unnecessarily complex, and subtype relationships can 
be introduced at the transition phase (see Section (1-C). 


HE FunctionDecl 0x5649b6a82788 <line:16:1, Line:20:1> Line:16:5 used whole_degree ‘int (int) 

FParmVarDecl 0x5649b6a826b8 <col:18, col:22> col:22 used 7 ‘int’ 

| EPropagation 0x5649b6a87698 ReasonStmt=(CallExpr 0x5649b6a88038 <Line:45:34, col:54> ‘int') Link=0x5649b6a87658 SourceDecl=(VarDecl 0x5649b 
$a85090 <Line:39:44, col:73> col:48 used desired 'int' cinit) TargetDecl=(ParmVarDecl 0x5649b6a826b8 <Line:16:18, col:22> col:22 used 7 'int') 

| *-Propagation 0x5649b6a87b10 ReasonStmt=(CallExpr 0x5649b6a88238 <Line:46:34, col:54> ‘int') Link=0x5649béa87ad9 SourceDecl=(VarDecl 0x5649b 
$a85090 <Line:39:44, col:73> col:48 used desired 'int' cinit) TargetDecl=(ParmVarDecl 0x5649b6a826b8 <Line:16:18, col:22> col:22 used * '‘int') 


*-CompoundStmt 0x5649b6a82c38 <col:25, Line:20:1> 
Dec lStmt 0x5649b6a82928 <Lline:17:3, col:21> 


*-BinaryOperator 0x5649b6a82908 <col:15, col:19> ‘int’ '/' 





L=(VarDecl 0x5649b6a82848 <col:3, col:19> col:7 used w! 





*-IntegerLiteral 0x5649b6a828d0 <Line:17:19> 'int' 10 
FDeclStmt 0x5649b6a82a38 <line:18:3, col:24> 


*-BinaryOperator 0x5649b6a82a18 <col:18, col:22> ‘int’ '%' 





*-IntegerLiteral 0x5649b6a829e@ <Line:18:22> 'int' 10 
*-ReturnStmt 0x5649b6a82c28 <line:19:3, col:50> 





$49b6a82788 <Line:16:1, Line:20:1> line:16:5 used w 
*-BinaryOperator 0x5649b6a82c08 <line:19:10, col:50> 'int' 'x' 
FParenExpr 0x5649b6a82bc8 <col:10, col:46> ‘int’ 
| *-ConditionalOperator 0x5649b6a82b98 <col:11, col:41> '‘int' 











Fig. 1. 


| FBinaryOperator 0x5649b6a82aa8 <col:11, col:23> 'bool' '2" 
| | FE ImplicitCastExpr 0x5649b6a82a90 <col:11> ‘int' <LValueToRValue> 
| | | F Link 0x5649b6a88d48 Normal SourceStmt=(DeclRefExpr 0x5649b6a82a50 <col:11> 'int' Lvalue Var 0x5649b6a82958 


*-VarDecl 0x5649b6a82848 <col:3, col:19> col:7 used whole ‘int’ cinit 


FE Link 0x5649b6a88af@ Local-Tree-Link SourceStmt=(BinaryOperator 0x5649b6a82908 <col:15, col:19> 'int' '/') SLink=<<<NULL>>> TargetDec 
le ‘int' cinit) TLink=<<<NULL >>> 

FImplicitCastExpr 0x5649b6a828f0 <col:15> ‘'int' <LValueToRValue> 

| HE Link 0x5649b6a88ab0 Normal SourceStmt=(DeclRefExpr 0x5649b6a828b0 <col:15> 'int' Lvalue ParmVar 0x5649b6a826b8 ‘1 
5649b6a88a70 TargetStmt=(DeclRefExpr 0x5649b6a828b0 <col:15> 'int' Lvalue ParmVar 0x5649b6a826b8 ‘7’ ‘int') TLink=0x5649b6a88a70 
| *-DeclRefExpr 0x5649b6a828b0 <col:15> ‘int’ lvalue ParmVar 0x5649b6a826b8 ‘1 
| *-Link 0x5649b6a88a70 Normal SourceDecl=(ParmVarDecl 0x5649b6a826b8 <Line:16:18, col:22> col:22 used | 'int') SLink=<<<NULL>>> Tar 
jetDecl=(ParmVarDecl 0x5649b6a826b8 <col:18, col:22> col:22 used | ‘int') TLink=<<<NULL >>> 


‘int') SLink=0x 


*ant* 


*-VarDecl 0x5649b6a82958 <col:3, col:22> col:7 used fracture ‘int’ cinit 


FE Link 0x5649b6a88c60 Local-Tree-Link SourceStmt=(BinaryOperator 0x5649b6a82a18 <col:18, col:22> ‘int’ '%') SLink=<<<NULL>>> TargetDec 
l=(VarDecl 0x5649b6a82958 <col:3, col:22> col:7 used fracture 'int' cinit) TLink=<<<NULL >>> 

FE ImplicitCastExpr 0x5649b6a82a00 <col:18> ‘int' <LValueToRValue> 

| F Link 0x5649b6a88c20 Normal SourceStmt=(DeclRefExpr 0x5649b6a829c8 <col:18> ‘int' Lvalue ParmVar 0x5649b6a826b8 ‘1° 
5649b6a88beO TargetStmt=(DeclRefExpr 0x5649b6a829cO <col:18> 'int' lvalue ParmVar 0x5649b6a826b8 ‘T° 
| *-DeclRefExpr 0x5649b6a829cO <col:18> ‘'int' lvalue ParmVar 0x5649b6a826b8 ‘| 
I “-Link 0x5649b6a88be® Normal SourceDecl=(ParmVarDecl 0x5649b6a826b8 <Line:16:18, col:22> col:22 used | ‘int') SLink=<<<NULL>>> Tar 
jetDecl=(ParmVarDecl 0x5649b6a826b8 <col:18, col:22> col:22 used | ‘int') TLink=<<<NULL >>> 


‘int') SLink=0x 
"int') TLink=0x5649béa88be0 
‘int' 


FLink 0x5649b6a88e88 Local-Tree-Link SourceStmt=(ReturnStmt 0x5649b6a82c28 <col:3, col:50>) SLink=<<<NULL>>> TargetDecl=(Functiondecl 0x5 
ole_degree ‘int (int)') TLink=<<<NULL >>> 


"int') S$ 


‘fracture 


Excerpt from the LLVM/Clang Abstract Syntax Tree (AST) representation extended with the fictive type graph labelling process for the 


int whole_degree (int) function of the example in Listing [4] The new node types Link and Propagation are indicated in soft blue. 


2) Operators: Operator applications between variables of 
user-defined types in C+ are represented as calls to a specially 
named function. Since such functions exist somewhere in 
the source code, propagating the taint to their parameters 
and return types work as expressed in the previous section. 
However, the operations on fundamental types do not exist in 
the code, only in the language specification, and the compilers 
“know” what semantics are associated with such operations. 
As we cannot annotate these operations, the model is extended 
with an additional environmental parameter. The operation 
map (Res) describes which operator applications over built-in 
types are defined in the fictive type dimension. For practical 
purposes, this is a configuration file created and edited by the 
user or a user-facing tool of the type migration process. An 
example of this configuration file is given in Listing 

Let us now establish the rules for operator applications: 
(7) For an unary operator *: ft(*y) = Res(*ft(y)) if 

defined, otherwise 70 
(8) For a binary operator @: ft(y@o) = Res(ft(y)@ ft(o)) 
if defined, otherwise /O 
(9) For a compound assignment operator ®=:|ft(y ®= 0)|= 
ft(y) iff ft(y) @ ft(c) = ft(y), otherwise 7m 

Note that in Rules the error states of an undefined 
operation are considered recoverable (70). In a practical 
scenario, the propagation can pause, and the user should be 
presented with the indication that a yet-unknown operation 
was encountered. If the user defines the operation to some 
result, the process may continue with the new information 
added. These customisation points make our proposed process 
exploratory. 

When performing the propagation for the example in List- 











ing/4| this question is raised in the context of what will become 
the temperature operator +(temperature, temperature)’ 
and bool operator <(temperature, temperature) func- 
tions when encountering the (T1 + T2) / 2 < desired ex- 
pression. 

Rule [()| mirrors the specification of operators such as +=, 
equivalent to x = x+y. The result of the operator is the left- 
hand expression, but the + operation must be defined in a 
type-compatible way. 


B. Type inference and backwards propagation 


It is tempting to consider the aforementioned rules to allow 
for type inference (48), e.g. when a binary operator call with 
only one side’s type known: ?+7’. If, in this case, the operation 
map contains precisely one entry where + is defined with T’ 
on the right-hand side, we might deduce that the left-hand side 
“must be” what is defined in the map. This could only be done 
if the user explicitly listed all possible operations in advance 
and decided to disable the exploratory nature of the process. 
While such an action is certainly possible and the model could 
support it, in case the user has a complete understanding of 
the specification of the migrated system, different approaches 
to the specific domain could be used instead. 

A similar issue arises with adding backwards propaga- 
tion to the model. Rules appear the most trivial 
to back-propagate. The issue with this back-propagation is 


“The accuracy at which the domain is modelled is up to the professional to 
decide. One could argue that temperature is a state quantity, which can not be 
added together. “Average temperature” exists as its own concept, but the sum 
of two temperatures might not inherently create a new “temperature” value 
— to raise or lower temperature, it is energy (a different concept, and thus a 
different fictive type) that must be transitioned through the (physical) system. 


[[fictive_type_inline]] int max(int x, int y) { 
return x < y? y: x 


} 


[[ft ("val") ]] int R1 = 4, R2 = 6; 

int MaxR = max(R1l, R2); 

Listing 8: Example for the inline attribute [c)] which replaces 
the propagation through the ia function with a summary. ia’s 
parameter is not tainted persistently, but MaxR receives the 
"val" taint that flowed through the function call. 


not theoretical but practical: running the process in parallel 
would require the back-propagation step to be after its distinct 
synchronisation, as propagating in two directions can result 
in misdiagnosis of conflicts. Back-propagation from the result 
type of operator applications in Rules are a special 
case of type inference, and the previously discussed concerns 
apply. 

Due to C and C+ mainly working in the imperative pro- 
gramming paradigm and the fact that the language specifies 
that program elements need to be declared before their usage, 
it is more in line with the developer thought process if 
back-propagation is not added as a complexity in the model. 
Instead, cases where back-propagation is appropriate remain 
as checkpoints in the logic where mismatch of fictive types 
— e.g. assigning a function return value 7’ to a variable 
that is declared U — are detected, but we do not intend to 
automatically apply the fictive type U instead of T' to the 
function by defining a reverse combination of Rules and 


2) 


C. Enforcing bounds on the taint spread 


In every software project, there exist sym- 
bols that should not be _ tainted. Consider the 
control_write (unsigned short, int) function in Line 
of Listing |4| If we “label” that wnole_degree (int) returns 
a temperature, the function calls in Lines pass this 
rounded temperature to the control_write function’s second 
parameter. Thus, by applying rule this second parameter 
should also be marked as a temperature. This would result 
in the call in Line to also expect that “icon_to_use is 
a temperature” — assigning any other fictive type to this 
variable would conflict with the parameter’s already received 
taints — which is not correct. 

To ensure that the executed algorithm can be contained and 
does not over-approximate what should be labelled, we created 
some additional annotations that the user can add to their code. 


e For any program element which may take a 
[[fictive_type(...)]] attribute, the following attributes 
sink the propagation process. 

a) [[fictive_type_ignore]] marks the node to be ig- 
nored entirely by the fictive type process. This node 
is not rewritten to a stronger type, and any taint that 
reaches it silently disappears. Program elements which 
definitions are external to the analysed project are 
ignored by default. 


[[ft ("temperature"})]] int T = 38; 


stdzcout << T; 


// [[fictive_type_overload]]| 
operator <<(ostreamé, 
temperature) ; 


// [[fictive_type_ignore]] 
operator <<(ostreamé, 
int); 


temperature T{38}; 
stdicout << 
static_cast<int>(T) ; 


temperature T{38}; 
stdzcout << T; 


Listing 9: The effect of tainting a commonly used function, 
such as the print-out operator. In one case, the decision is to 
ignore the type taint. In the other case, the decision is to 
create a new overload (dp. 


b) [[fictive_type_barrier]] marks the node not to be a 
source of a taint. Such a node may still receive a fictive 
type and be replaced with a stronger type at the end 
of the process, but it does not further spread its label. 

e Functions are enhanced with the possibility of two more 
attributes. 

c) [[fictive_type_inline]] may only apply to functions. 
If a function symbol is attributed, a summary is gener- 
ated [49], and at usage points, this summary is inlined 
and used instead of tainting the function’s parameters 
directly by applying Rules |(4)] or 

d) [[fictive_type_overload]] specifies that instead of 
tainting the attributed function’s parameters or unbox- 
ing the strong interface at the function call, a new 
overload with the tainting type should be generated 


(see Section |III-C) instead. 


We define and try to establish the following two summaries 
for each annotated function. Either parameter p, taints another 
parameter, p,; or parameter p, taints the return value of the 
function. An example of the latter case is depicted in Listing [8] 

Printing values to the 
monly implemented by overloading the 
stdostream& operator <<(std:ostreams, T); function. If 
a to-be-migrated new variable reaches such a print-out, the 
function parameter would be a candidate for type migration. 
This must not be done, especially for built-in types, as 
the implementation is coming from the standard library. In 
this case, there are two choices between which the user 
can decide. The decision depends on the exact semantics 
associated with the new type post-migration. The effect of 
the individual decisions is depicted in Listing [9 


output is com- 


e Ignore the function call in the fictive type domain and do 
not taint. In this case, the unboxing of the strong type is 
added to the call and the original implementation taking 
the original type, will be used. 

e Specify that an overload should be created instead. In 
this case, the function call is not changed as the call 
will be type-conforming post-migration. The automatic 
unboxing of the wrapped value — and thus the fallback to 
the original function — is contained in the new function. 


For example, temperatures are usually associated with a mea- 
surement unit. The decision to overload the print-out operator 
for this new type would be more beneficial as there would be a 
well-defined location, the new overload, where adding the unit 
to a human-readable output could take place. As overloaded 
functions and user-defined operators are not possible in C, this 
option is not available for migrations that are to take place in 
strictly C projects. 


V. FUTURE WORK 


There are several improvements to our proposed approach 
that we intend to investigate in the future. First, due to 
macros, the C+ compilation model and most tools built upon 
a compiler are designed for running on one input file of 
one environment configuration and emitting one result. This 
means that the interactive process cannot discover usages 
of an introduced fictive type (as described in Section |II) 
that are conditionally not compiled in the analysed version 
of the software. The relatively recent but since ubiquitous 
Language Server Protocol allows integration of tools such 
as one conceived by us with integrated developer environments 
(IDEs) through a common and open-source protocol definition 
to exchange diagnostics, semantic highlighting, etc. It should 
be investigated how the presented process can be abstracted 
and implemented for other programming languages. As such, 
it should be offered as a generic refactoring, maybe under the 
name ’Extract type”. For example, the CLion IDE offers an 
"Extract typedef” [51] refactoring action. 

Certain constructs in the C+ language do not synergise 
well with the attribute syntax. The most notable of these are 
templates, which is particularly problematic as templates are 
also one of the main selling points of C+. An annotation 
on a concrete template instantiation’s type parameter, as seen 
in Listing is not syntactically valid. This means that we 
need to investigate Section|IV}s previously defined propagation 
rules and extend them with rules that handle templates. This 
will most likely result in the creation of an attribute such as 
[[fictive_type_template_arg(1, However, 
due to the complexity of template metaprogramming (52). both 
as a language element and a practical implementation of it in 
a parser, we plan to investigate this in the future. 

Moreover, during our research, we have regularly found 
ourselves observing the idea of allowing multiple fictive 


"housepet") ]]. 


types on the same declaration — [[fictive_type("a"), 
fictive_type("b") ]] — or multiple type identifiers in the same 
fictive type attribute — [[fictive_type("a", "b")]]. Cur- 


rently, such annotations are syntactically invalid and rejected 
as the model is not designed to handle them. A node receiving 
multiple types is considered the indication that the programmer 
conflated distinct domain concepts in a shared usage point. 
While we have yet to inquire and define the possible semantics 
for these new constructs, we believe the former construct 
could allow our model to express transitioning to disjunctive 
or “either” types (union), while the latter could express record 
types or tuples in the fictive type axis. 


template <typename ElementType> 
struct vector { /* ... */ }j; 


class Animal; 
void feed_daily ([[fictive_type ("housepet") ]] Animalé) ; 


void f (vector<[[fictive_type (housepet) ]] Animal> 
animals) { 
for (Animal& a : animals) 
// Only feed pets, not potentially wild animals. 
feed_daily (a); 
} 
Listing 10: Annotating the element type of a vector instantia- 
tion to express that the vector should later be type migrated to 
only contain pets. The highlighted annotation is not handled 
in the model, as attributes commonly appear on declarations 
and not types, and the Animal is a template type parameter. 
Annotating the parameter animals is not equivalent to our 
intent, as we need to convey the information that the loop 
variable a is the "housepet". 


VI. CONCLUSION 


The lack of finely detailed types in software projects is 
ground for various issues that may lead from subtle mistakes 
to financial and life-threatening catastrophes. While various 
programming languages support strong aliases or constrained 
types out of the box, in other modern programming languages, 
users need to resort to third-party libraries or writing the types 
themselves. Unfortunately, developers tend to overuse coarse- 
grained types in many cases, such as when it comes to compu- 
tations with scalars and textual data. Existing approaches of 
type migration are either completely domain-specific or fail 
due to the broadness of usages of built-in types like int. 

In this paper, we presented fictive types. This approach that 
allows the incremental discovery of usages based on data flow 
and graph colouring, initiated by a developer marking a pro- 
gram element to be migrated. A compiler-based tooling, aided 
by interaction with the developer, generates the discovery of 
affected expressions. During this work, information is encoded 
in the source text in a syntactically valid, but to traditional 
compilers transparent way. After the propagator iteration is 
over, the new strong interface is generated automatically and 
existing compilers can detect any subsequent type violations 
through the usual type checking required by the language. In 
addition, the collision of different annotations on the same 
node indicates that two or more conceptually different types 
are mixed in the same symbol, which — before fictive types 
were introduced — had the same type. In this case, a manual 
fix is needed, and we report this situation to the user. 

Once the project has successfully transitioned to stronger 
types through using the process described, other enhancement 
and refactoring approaches, such as invariant synthesis, might 
be run on the code to further the effort for proper type safety. 
While our approach is discussed from a C+ point-of-view, the 
idea can also be applied to other languages, if there is a way 
for transparent, user-defined annotations (such as in Java) and 
custom syntax representation aware tools to exist. 
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